A publish/subscribe system is a mechanism where subscribers express interest in future information by some selection criterion, publishers provide information, and the mechanism delivers the information to all interested subscribers. Current publish/subscribe systems organize information around topics (also called channels, subjects or streams). Providers or publishers publish events to topics and consumers or subscribers subscribe to all data from a particular topic.
Exemplary publish/subscribe systems are stock data systems (the stock exchange publishes the stock ticker and the subscribers choose which stocks they are subscribed to) and cable television systems (the cable companies publish the channels and the subscribers choose which channels to pay for. Usually, the subscribers choose set packages of channels).
The publisher may define a large number of topics and the topics may be organized hierarchically in a tree to reflect the information structure and to facilitate user access control. Topics, or information delivery channels, are mapped to the underlying network infrastructure, based either on multicast transport or unicast transport, or on a combination of the two. Several topics are often transmitted over one multicast group. Moreover, in order to reduce processing and networking overhead, messages from different topics are typically packed into a single network packet. The latter is described in an article by Carmeli, B et al., “High Throughput Reliable Message Dissemination”, Symposium on Applied Computing, March 2004 and in U.S. patent application Ser. No. 10/699,081 entitled “Minimal Delay Transmission of Short Messages”.
Subscribers who are interested in a topic join the multicast group where the topic is transmitted. Unfortunately, the subscribers not only receive the messages from their topic of interest but they also receive messages on other topics transmitted with the same group. These latter messages need to be filtered out by the receiving device at the subscriber. Typically, the filtering process may apply a pattern matching or regular expression filter on the “Topic Name” (a string header-field) to reject or accept a message, for every message individually. Such a filter is described in U.S. Pat. No. 5,557,798 to Skeen et al.
Unfortunately, topic names are often long strings, usually of variable length, which renders pattern matching a demanding procedure. Moreover, the topic name is also used to demultiplex the message; that is, to deliver it to the correct consumer in the application layer. This task is not unique to multicast; in unicast transport, multiple topics are often sent over a single connection to each client and each client has to demultiplex the data to its application subscribers. Regardless of transport type, the long, variable length topic strings are ill-suited for demultiplexing. Often, the processing load required for topic-based message filtering and demultiplexing in receivers becomes the performance bottleneck, precluding the system from meeting application throughput requirements. These requirements are particularly tight in front-offices of the financial sector since the latter are characterized by high data flow volumes.
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.